Seems good for me. Thanks for your work!

cc @nikomatsakis @jonathandturner

I like the idea of changing the wording for better readability.

I'm not 100% yet on "value Foo is not declared in this scope". If we're going to change away from resolved (which sounds 👍 to me), do we want to change to declarations and scopes? It seems like we're trading one bit of terminology for another.

Curious to hear what @nikomatsakis thinks, but how does "value Foo is not visible from here" sound? May need a little tweaking but seems to be a little less jargon-y.

LGTM, I like the wording.

@jonathandturner I feel like 'declared' and 'scope' are not as bad as 'resolution' - the former are programming jargon, but the latter is compiler jargon. So while it is not perfect, it is much better.

I'm wary about using 'visible' since it seems easy to confuse with visibility (is a variable declared in a scope, vs is the variable accessible from that scope).

r=me, but leaving open for a few days for discussion of wording.

Strong 👍 on shifting away from "resolved". I have to admit I find it hard to imagine not knowing the word "declaration", but I can appreciate that I am biased and that this might well be the case for some users! That said, I don't like the precise wording of "value Foo is not visible from here" -- the problem is that, to me, that implies that Foo exists but there is a privacy violation or something else (maybe a missing use) that is preventing me from "seeing" it. But really Foo might not even be a type that is declared anywhere, right? Maybe something like "cannot find a type named Foo"?

@nikomatsakis

But really Foo might not even be a type that is declared anywhere, right? Maybe something like "cannot find a type named Foo"?

Compare messages for

mod m {
    pub struct Foo;
}

fn main() {
    Foo;
}

1. "not in scope"

error[E0425]: value `Foo` is not declared in this scope
 --> test.rs:6:5
  |
6 |     Foo;
  |     ^^^ not in scope
  |
  = help: possible candidate is found in another module, you can import it into scope:
  = help:   `use m::Foo;

2. "can't find"

error[E0425]: cannot find a value named `Foo`
 --> test.rs:6:5
  |
6 |     Foo;
  |     ^^^ cannot find `Foo`
  |
  = help: possible candidate is found in another module, you can import it into scope:
  = help:   `use m::Foo;

In the second case we tell that we can't find Foo, but in fact we can find Foo in another module and even suggest to import it into scope. So, mentioning "scope" seems desirable.

What about "cannot find ... in scope"? With the notes being about something with that name being "found elsewhere". This seems better than mentioning declarations which can be confusing wrt imports and other things.

What about "cannot find ... in scope"?

Base 1: cannot find <struct> <S> in this scope
Label 1: not in scope
Base 2: cannot find <struct> <S> in <module> <a::b>
Label 2: not in <a::b> (???)

LGTM (except for label 2), but I have nothing against "declared" so I like my variant better.

@petrochenkov one think that gives me pause about "declared" is that I think of a declaration as being something like struct Foo -- but a use statement doesn't feel like a declaration. Therefore, when I see an error "no Foo declared in scope" it suggests to me that the only way to have Foo be a valid name for me to use is for me to declare an item with that name, which is not the case. I think for this reason I prefer "cannot find".

I think mentioning scope is ok though. So 👍 to the latest iteration from me.

I'm still interested in better suggestions for "Label 2".

@petrochenkov what an example for label 2?

I see the pattern, but what does it look like a real example?

@jonathandturner
Code:

mod m {
    pub mod n {
        pub struct Foo;   
    }
}

fn main() {
    let foo = m::Foo;
}

Diagnostics:

error[E0425]: cannot find value `Foo` in module `m` (BASE 2)
 --> test.rs:8:15
  |
8 |     let foo = m::Foo;
  |               ^^^^^^ (LABEL 2)
  |
  = help: possible candidate is found in another module, you can import it into scope:
  = help:   `use m::n::Foo;`

(Note that path segments don't have individual spans now, so the label has to point to the whole path.)

I think it's okay to also use "not in scope" here, too

cannot find value m::Foo in module m

I wonder why this isn't/can't be "cannot find value Foo in module m".
As for the LABEL 2, "not found in m" seems reasonable to me.

EDIT:

(Note that path segments don't have individual spans now, so the label has to point to the whole path.)

We should just fix this, it's been bothering me for other reasons (per-segment lifetime/type parameters).

I wonder why this isn't/can't be "cannot find value Foo in module m".

Oh, that's just a typo (I modified the error message manually), fixed.

We should just fix this

Ok, I'll use "not in m" then, an add new spans later in a separate PR.

☔ The latest upstream changes (presumably #38925) made this pull request unmergeable. Please resolve the merge conflicts.

New messages are looking good. 👍

Updated.

@bors: r+

📌 Commit 2c6fa8a has been approved by nrc

Fixed wrongly updated UI test caught by travis
@bors r=nrc

📌 Commit 2092682 has been approved by nrc

⌛ Testing commit 2092682 with merge 2768428...

💔 Test failed - status-appveyor

dist failure (appveyor s3 bindings)
@bors retry

⌛ Testing commit 2092682 with merge 31f0c9d...

💔 Test failed - status-travis

@bors: retry

• docker failed to start Spurious failure when starting docker on Travis #39035

⌛ Testing commit 2092682 with merge 3e5621b...

⌛ Testing commit 2092682 with merge 1d5fb06...

☀️ Test successful - status-appveyor, status-travis
Approved by: nrc
Pushing 1d5fb06 to master...